Methods and Systems for Establishing Communications Through Firewalls and Network Address Translators

ABSTRACT

Disclosed are methods that enable communications to be established regardless of the presence of communications blockers, e.g., firewalls and NATs, in the path between two computing devices. Two devices each establish communications with a rendezvous service. Through the service, the devices signal each other to set up direct, peer-to-peer communications between themselves. If the devices fail to establish direct communications, then they invoke a relay service that provides the illusion of direct communications. In another aspect, an originating device attempts to establish communications with a recipient, using an address and port number associated with the recipient. If that attempts fails, possibly because a firewall is blocking communications, then the originating device retries using a port normally held open by firewalls. If this attempt also fails, then the originating device invokes the services of a proxy to negotiate a port acceptable for use by the recipient and by any intervening firewalls.

RELATED APPLICATIONS

This application in a continuation of U.S. patent application Ser. No.10/024,090 filed on Dec. 17, 2001.

TECHNICAL FIELD

The present invention relates generally to computer communications, and,more particularly, to communications flowing through a firewall or aNetwork Address Translator.

BACKGROUND OF THE INVENTION

The growth of networks, specifically the Internet, is spurring aproliferation of applications based on peer-to-peer computercommunications. In the older host-sever paradigm, a user took advantageof services provided by a more or less centralized corporate entity. Inpeer-to-peer communications, a user at one computing device communicatesin real time directly with a user at another device. Computer telephony,teleconferencing, interactive games, and remote collaboration are just afew examples of increasingly popular applications that take advantage ofinexpensive peer-to-peer communications.

It has long been possible to provide the illusion of peer-to-peercommunications by means of a relay service. When two users wish tocommunicate, each logs on to the relay service and directs itscommunications to the relay service. The relay service receives thecommunications and forwards them on to their intended recipient. Thisapproach is very useful as long as the amount of data transferred issmall and the latency requirements are lax, but in cases that demandlarge bandwidth and real-time response, the relay service quicklybecomes a traffic bottleneck. In addition, setting up and running alarge relay service are quite expensive in terms of money and resources.Ideally, peer-to-peer applications can operate without the mediation ofa relay service, but relays are still useful in providing connectivitywhen, for some reason, direct peer-to-peer communications are notpossible.

Direct communications may not be possible if a “communications blocker”sits on the path between the peer computing devices. A firewall is afirst example of a communications blocker. For security's sake, manyusers install firewalls between their computing devices andcommunications networks. Most firewalls protect computing devices byblocking incoming and outgoing communications except that which comesover specifically allowed addresses and ports. (Modern communicationsprotocols, such as the Internet Protocol (IP), allow for thespecification of source and destination fields called “ports,” inassociation with the source and destination addresses. Ports are oftenused to differentiate messages intended for separate processes runningon a single computing device.) If a peer-to-peer application attempts toreach a computing device behind a firewall, the firewall may preventcommunications from ever reaching the device. Even for communicationsdirected to an open port on the firewall (e.g., port 80 is usuallyopen), the port may be handling so much traffic from other sources thatreal-time response requirements cannot be met.

Another potential blocker of peer-to-peer communications is the NetworkAddress Translator (NAT). Ideally, each computing device connected tothe Internet is assigned a unique network address within the publicaddress space. The growth of Internet connectivity, however, has rapidlydepleted the supply of public addresses. To compensate, many computingdevices today do not have public addresses but are, rather, assignedprivate addresses outside the public address space. Having disparateaddress spaces leads to complications, however. For example, a devicewith a private address cannot send a message to a device with a publicaddress unless the private address is first translated to some publicaddress. NATs automatically perform this translation by interceptingpackets from the device with the private address and then replacing thedevice's private address in the packet header with the NAT's own publicaddress. The packet is then sent along to the outside device with thepublic address. The NAT stores a mapping between the private address ofthe device behind the NAT and the public address of the device outsidethe NAT. When communications arrives from the outside device addressedto the public address of the NAT, the NAT refers to this mapping andreplaces its own public address in the packet header with the privateaddress of the device behind the NAT. By way of this mapping, the devicebehind the NAT can both send communications to and receivecommunications from a device in the public address space.

The NAT translation scheme is based on the premise that communicationsare initiated by the computing device behind the NAT. The NAT must firstset up the translation mapping before it can know how to handlecommunications coming from the public network address space. Were adevice in the public address space to attempt to initiate peer-to-peercommunications by sending a message to the public address of the NAT,then, upon receiving the message, the NAT would search for a translationmapping for the sender's public address but would not find one. The NATwould discard the message, and the communications would fail. Thisproblem is compounded when each device is behind its own NAT. In thiscase, neither device can initiate communications: while the NAT of thecommunications initiator sets up its translation mapping, the NAT of therecipient does not have an appropriate mapping and discards the incomingmessage. Communications never start. As NATs proliferate, thisshortcoming impedes the spread of any application based on directpeer-to-peer communications.

Note that in the context of this application, “firewall” and “NAT” referto services, not necessarily to specific devices. These services may beprovided on separate hardware boxes, may be combined into one box, andmay even be instantiated as software running on the computing deviceitself.

A known approach to the problem of NATs sets up a signaling exchangebetween a computing device behind a NAT and the NAT. (The discussion ofthe current paragraph applies as well to firewalls as it does to NATs,but only NATs are discussed to avoid repetition or having to repeatedlywrite “NAT/firewall.”) The device sends a message directly to the NAT.The message directs the NAT to allow the communications channel neededfor a peer-to-peer application. However, this approach has itsdrawbacks. First, it forces the device to discover its NAT and to takethe NAT's presence into account. Traditionally, devices did not need toknow whether they sat behind a NAT: the NAT's operation was completelytransparent. Second, because NATs operate automatically by interceptingcommunications and then discarding them or passing them along, nostandard protocol exists to facilitate the signaling exchange. Addingthat capability greatly alters the architecture of a NAT, which hasoften been an uncomplicated, firmware-based device. These considerationsare compounded if the device sits behind a chain of multiple NATs orfirewalls, some of which may be located far from it, such as at thefacilities of the device's Internet Service Provider (ISP). The devicemay not be aware of all of these NATs and firewalls and may not have anymeans or permissions to communicate directly with them.

What is needed is a method for establishing communications that operatestransparently to any communications blockers, e.g., firewalls, NATs, orwhat have you, in the communications path between peer computingdevices.

SUMMARY OF THE INVENTION

The above problems and shortcomings, and others, are addressed by thepresent invention, which can be understood by referring to thespecification, drawings, and claims. According to a first aspect of thepresent invention, two computing devices each establish communicationswith a rendezvous service. Each device can communicate with therendezvous service regardless of the presence of communicationsblockers, such as firewalls or NATs, in the communications path betweenthe device and the service. Through the rendezvous service, the twocomputing devices signal each other and coordinate their activities insetting up direct, peer-to-peer communications between the two devices.The signaling mechanism through the rendezvous service allows eithercomputing device to attempt to establish communications. If both devicesfail to establish direct, peer-to-peer communications, then they invokethe services of a relay service that provides the illusion of directcommunications.

According to another aspect of the invention, usable separately or inconjunction with the first aspect, an originating computing deviceattempts to establish communications with a recipient computing device.The originating device uses an address and port number associated withthe recipient computing device. If that attempts fails, possibly becausea firewall is blocking communications, then the originating deviceretries using a port normally held open by firewalls. If this attemptalso fails, then the originating device invokes the services of a proxyto negotiate a port acceptable for use by the recipient device and byany intervening firewalls.

The present invention, through its diverse aspects, enablescommunications to be established regardless of the presence ofcommunications blockers in the path between two computing devices.

BRIEF DESCRIPTION OF THE DRAWINGS

While the appended claims set forth the features of the presentinvention with particularity, the invention, together with its objectsand advantages, may be best understood from the following detaileddescription taken in conjunction with the accompanying drawings ofwhich:

FIG. 1 a is a network schematic from the prior art showing one computingdevice behind a NAT and another computing device outside the NAT;

FIG. 1 b is a network flow diagram from the prior art showing thecomputing device behind the NAT of FIG. 1 a initiating communicationswith the computing device outside the NAT;

FIG. 1 c is a data table diagram from the prior art showing the NAT'stranslation mapping that facilitates the communications of FIG. 1 b;

FIG. 1 d is a network flow diagram from the prior art showing that thecomputing device outside the NAT of FIG. 1 a cannot initiatecommunications with the computing device behind the NAT;

FIG. 2 is a network flow diagram from the prior art showing how afirewall blocks communications on addresses and ports not specificallyallowed;

FIG. 3 is a block diagram generally illustrating an exemplary computersystem that supports the present invention;

FIGS. 4 a, 4 b, and 4 c are network flow diagrams of scenarios in whichtwo computing devices attempt to establish peer-to-peer communicationswith the aid of a rendezvous service;

FIGS. 5 a, 5 b, and 5 c are combination flow charts and data flowdiagrams of exemplary methods usable by the computing devices andrendezvous service in the scenarios of FIGS. 4 a, 4 b, and 4 c,respectively;

FIG. 6 is a network flow diagram of a scenario in which a computingdevice attempts to establish communications with its peer device in thepresence of a firewall; and

FIGS. 7 a, 7 b, and 7 c are a combination flow chart and data flowdiagram of an exemplary method for a computing device to use in thescenario of FIG. 6.

DETAILED DESCRIPTION OF THE INVENTION

Turning to the drawings, wherein like reference numerals refer to likeelements, the invention is illustrated as being implemented in asuitable computing environment. The following description is based onembodiments of the invention and should not be taken as limiting theinvention with regard to alternative embodiments that are not explicitlydescribed herein. Section I presents devices that often stymie attemptsto establish direct, peer-to-peer communications between two computingdevices. Section II presents an exemplary computing environment in whichthe invention may run. Section III describes exemplary embodiments ofthe invention's methods.

In the description that follows, the invention is described withreference to acts and symbolic representations of operations that areperformed by one or more computing devices, unless indicated otherwise.As such, it will be understood that such acts and operations, which areat times referred to as being computer-executed, include themanipulation by the processing unit of the computing device ofelectrical signals representing data in a structured form. Thismanipulation transforms the data or maintains them at locations in thememory system of the computing device, which reconfigures or otherwisealters the operation of the device in a manner well understood by thoseskilled in the art. The data structures where data are maintained arephysical locations of the memory that have particular properties definedby the format of the data. However, while the invention is beingdescribed in the foregoing context, it is not meant to be limiting asthose of skill in the art will appreciate that various of the acts andoperations described hereinafter may also be implemented in hardware.

I. Communications Blockers: NATs And Firewalls

Although the present invention does not involve changes to NAT orfirewall functionality, it is important to understand thosefunctionalities in order to understand the invention. FIG. 1 a shows aprior art networking arrangement that is the basis for the followingdiscussion of NATs and of the invention. In the Figure, a computingdevice 100 is connected via a local area network (LAN) 102 to a NAT 104.The NAT also has a connection to a public address space, hererepresented by the Internet 110. The network address 106 used on the LANis a private address, that is to say, it is not valid in the publicaddress space beyond the NAT. Because of this, device 100 cannotcommunicate with a computing device 112 in the public address spaceunless the private address 106 of device 100 is first translated. TheNAT is responsible for this translation, and the mechanism oftranslation is described below with respect to FIG. 1 b. Unlike thefirst device 100, device 112 has a public network address 114 that needsno translation. Note that while IP addresses are a standard for theindustry, the example addresses (106, 108, and 114) are intentionallyshown in a non-IP format to indicate that the invention is not limitedto any particular addressing format.

FIG. 1 b, also from the prior art, shows how NAT 104 facilitatescomputing device 100 in setting up communications with the computingdevice 112. Device 100 addresses an initial message to the publicnetwork address 114 of device 112. The initial message follows the path116. Although the message is not addressed to the NAT, the NATintercepts it and reads the “to address” field in the message's header.Because that field contains public network address 114, the NAT knows tosend the message out on its connection to the Internet 110. However, themessage as written by device 100 is not valid for the public addressspace because the “from address” field in the message's header containsthe private network address 106 of device 100. The NAT replaces thisprivate address with its own public address 108. The NAT also creates anaddress translation mapping that correlates the private network address106 of device 100 with the public network address 114 of device 112.FIG. 1 c shows this mapping in the translation table 118. Then, the NATsends the altered initial message on its way. The initial messagetravels via the Internet 110 and is received by the destination device112.

The message path 116 has an arrowhead at one end to indicate that it isthe path for initiating communications between computing devices 100 and112. That same path is traversed in the opposite direction by a responsesent from device 112 to device 100 (although the exact path through theInternet 110 is immaterial). Device 112 addresses its response to the“from address” found in the header of the message it received. Becauseof the NAT's earlier translation, that address is actually the NAT'spublic address 108. When the NAT receives the response message, itsearches its translation table 118 for the message's “from address” inthe column pertaining to the interface over which the NAT received themessage. The response message comes over the NAT's external networkconnection. In the “External Network Address” column of table 118 is anentry corresponding to the “from address” in the response message.Having found the appropriate address translation entry, the NAT removesits own external network address from the “to address” field of themessage's header and substitutes for it the internal network addressindicated by the mapping. In this case, that is (1.2.3), the address ofdevice 100. In this manner, the NAT's address translation allows devices100 and 112 to communicate with each other.

Computing devices 100 and 112 can communicate as long as the translationentry exists in the NAT's address translation table 118. For the sake ofsecurity and to preserve memory resources, the NAT does not store thetranslation mapping forever. Some NATs remove the translation after aperiod of inactivity. This timeout period may depend upon the type ofthe communications and is typically on the order of hours forTransmission Control Protocol (TCP) communications and minutes orseconds for User Datagram Protocol (UDP) communications. Other NATs maymonitor the communications flow and discard the translation when oneside or the other indicates that the conversation is over.

Note that the success of the NAT's translation scheme depends upon thefact that the computing device behind the NAT, here device 100, sendsthe initial message to initiate communications. FIG. 1 d, again from theprior art, shows what happens when, instead, the computing device 112attempts to initiate communications with device 100. Because the privatenetwork address 106 of device 100 is invalid in the public address spaceof the Internet 110, device 112 addresses its initial message to thepublic address 108 of NAT 104. This initial message follows the path120. Just as when the NAT received the response message in the scenarioof FIG. 1 b, the NAT looks for an address translation mapping in itstable 118. However, in the scenario of FIG. 1 d the mapping shown inFIG. 1 c does not exist because device 100 never sent a message throughthe NAT to device 112. Without the mapping, the NAT cannot translate the“to address” field in the message's header to a private network addresson LAN 102. The message is discarded. Thus, in the prior art, acomputing device outside of a NAT cannot initiate communicationsdirectly with a device behind the NAT. The problem is exacerbated wheneach computing device is behind its own NAT: then neither device caninitiate communications with the other.

FIG. 2 portrays another common communications blocker. The NAT 104 ofFIG. 1 a is replaced by a firewall 200. For purposes of the presentdiscussion, a firewall may be thought of as blocking all communications,based on their addresses and port numbers, that have not beenspecifically allowed. For example, assume that the firewall is set up toallow communications between the computing device 100 and all devices,such as device 112, in the public address space of the Internet 110.However, the firewall only allows traffic directed to ports 80 and 443.In the Figure, device 100 sends communications 202 directed to port 80,address (12.9.7), the public address of device 112. The firewall passesthese communications unaltered. If device 112 were to attempt tocommunicate with device 100 on port 1234, as in communications flow 204,however, the firewall would prevent the communications from reachingdevice 100. Firewalls present problems for real-time, peer-to-peerapplications because, although a port can almost always be found that isopen for communications through the firewall (e.g., port 80 is usuallyopen), that port may be handling so much traffic from other sources thatreal-time response requirements cannot be met.

The similarity in the icons for NAT 104 introduced in FIG. 1 a and thefirewall 200 of FIG. 2 is suggestive: these two services are oftenprovided by the same piece of hardware. In some cases, that hardware maybe part of computing device 100.

II. An Exemplary Computing Environment

The computing devices 100 and 112 of FIG. 1 a may be of anyarchitecture. FIG. 3 is a block diagram generally illustrating anexemplary computer system that supports the present invention. Computingdevice 100 is only one example of a suitable environment and is notintended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should computing device 100 beinterpreted as having any dependency or requirement relating to any oneor combination of components illustrated in FIG. 3. The invention isoperational with numerous other general-purpose or special-purposecomputing environments or configurations. Examples of well-knowncomputing systems, environments, and configurations suitable for usewith the invention include, but are not limited to, personal computers,servers, hand-held or laptop devices, multiprocessor systems,microprocessor-based systems, set-top boxes, programmable consumerelectronics, network PCs, minicomputers, mainframe computers, anddistributed computing environments that include any of the above systemsor devices. In its most basic configuration, computing device 100typically includes at least one processing unit 300 and memory 302. Thememory 302 may be volatile (such as RAM), non-volatile (such as ROM,flash memory, etc.), or some combination of the two. This most basicconfiguration is illustrated in FIG. 3 by the dashed line 304. Thecomputing device may have additional features and functionality. Forexample, computing device 100 may include additional storage (removableand non-removable) including, but not limited to, magnetic and opticaldisks and tape. Such additional storage is illustrated in FIG. 3 byremovable storage 306 and non-removable storage 308. Computer-storagemedia include volatile and non-volatile, removable and non-removable,media implemented in any method or technology for storage of informationsuch as computer-readable instructions, data structures, programmodules, or other data. Memory 302, removable storage 306, andnon-removable storage 308 are all examples of computer-storage media.Computer-storage media include, but are not limited to, RAM, ROM,EEPROM, flash memory, other memory technology, CD-ROM, digital versatiledisks (DVD), other optical storage, magnetic cassettes, magnetic tape,magnetic disk storage, other magnetic storage devices, and any othermedia that can be used to store the desired information and that can beaccessed by device 100. Any such computer-storage media may be part ofdevice 100. Device 100 may also contain communications connections 310that allow the device to communicate with other devices. Communicationsconnections 310 are examples of communications media. Communicationsmedia typically embody computer-readable instructions, data structures,program modules, or other data in a modulated data signal such as acarrier wave or other transport mechanism and include any informationdelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics set or changed in such a manner as toencode information in the signal. By way of example, and not limitation,communications media include wired media, such as wired networks(including LAN 102 of FIG. 1 a) and direct-wired connections, andwireless media such as acoustic, RF, infrared, and other wireless media.The term “computer-readable media” as used herein includes both storagemedia and communications media. Computing device 100 may also have inputdevices 312 such as a keyboard, mouse, pen, voice-input device,touch-input device, etc. Output devices 314 such as a display, speakers,printer, etc., may also be included. All these devices are well know inthe art and need not be discussed at length here.

III. The Invention in Operation: NATs, Firewalls, And Rendezvous AndRelay Services

FIGS. 4 a, 4 b, and 4 c present example scenarios in which two computingdevices, 100 and 112, attempt to establish direct, peer-to-peercommunications with each other. FIGS. 5 a, 5 b, and 5 c, respectively,illustrate exemplary methods that the devices may use in thesescenarios. In an attempt to forestall the connection problemsillustrated in FIGS. 1 d and 2, a rendezvous service 400 is provided.Computing devices can freely establish communications with therendezvous service, typically by logging on to it. The devices can thendiscover other devices with which they wish to communicate and can sendconnection information to other devices by way of the service. This ismade clearer by the examples described below. MICROSOFT'S “MSNMESSENGER” is an example of a rendezvous service.

Note that in the examples of FIGS. 4 a, 4 b, and 4 c, the communicationsblocker in front of computing device 100 is labeled “NAT/Firewall”: thisrepresents any type of communications blocker, be it a NAT, a firewall,a combination of the two, or something else entirely. The particulars ofthe blocker's operation are not relevant to these examples.

In the first example, illustrated by FIGS. 4 a and 5 a, computingdevices 100 and 112 establish communications flows, 402 and 404,respectively, with the rendezvous service 400. While the correspondingsteps, 500 and 502, of FIG. 5 a are shown as occurring simultaneously,that need not be the case. Possibly using a discovery or naming serviceprovided by the rendezvous service, device 112 decides to communicatewith device 100. In step 504, device 112 invites device 100 to establishcommunications. The invitation is sent to the rendezvous service ratherthan directly to device 100. In step 506, the rendezvous serviceattempts (after possible translations not relevant to the presentdiscussion) to pass the invitation along to device 100. Even thoughdevice 100 is behind the communications blocker 104/200, the alreadyestablished communications flow 402 allows the invitation to reachdevice 100. Upon receiving the invitation, device 100 in step 508attempts to establish communications with device 112. Because there isno communications blocker in front of device 112, the attempt succeedsand devices 100 and 112 establish communications flow 406 with oneanother. In the parallel steps 510 and 512, devices 100 and 112 usecommunications flow 406 to communicate directly with one other. Note theimportance of the directness of communications flow 406: it does notpass through the rendezvous service. That service is used only forsignaling during establishment of the direct, peer-to-peer connection.

The example scenario of FIG. 4 a is not symmetric because computingdevice 100 is behind a communications blocker 104/200 while device 112is not. The second scenario of FIGS. 4 b and 5 b shows what may happenwhen, opposite to the example of FIGS. 4 a and 5 a, device 100 invitesdevice 112 to establish communications. The procedure begins as beforein steps 500 and 502 with the two devices establishing communicationswith rendezvous service 400. This time, device 100 sends, via therendezvous service, an invitation to device 112 to establishcommunications (steps 514 and 516). When in step 518, device 112attempts to establish communications flow 408, its attempt fails becauseof the communications blocker 104/200 in front of device 100. (Note thatthe presence of a communications blocker need not doom this attempt tofail. The blocker may allow the communications in which case thisattempt successfully establishes the communications flow as in theprevious scenario. The procedures of FIG. 5 b only proceeds if step 518fails.) Device 100 becomes aware of device 112's failure. That awarenessmay arise when the rendezvous service uses communications flow 402 topass on a failure message sent to it from device 112. Alternately,device 100 may time how long it takes device 112 to establishcommunications. If the timer goes off before communications areestablished, device 100 decides that device 112 failed. In any case,device 100 now attempts, in step 520, to establish communications flow410 with device 112. Just as in the scenario of FIGS. 4 a and 5 a, thisattempt succeeds because there is no communications blocker in front ofdevice 112. In the parallel steps 522 and 524, devices 100 and 112 usecommunications flow 410 to communicate directly with one other.

Comparing the two scenarios presented so far, one may be tempted tothink that the procedure of FIG. 5 b is extraneous because devices wouldsimply choose to use the procedure of FIG. 5 a and have the devicebehind the communications blocker always be the one to attempt toestablish the communications. The situation is not so straightforward,however, because a device cannot always know whether or not it is behinda communications blocker. The invention is designed to work regardlessof whether either or both devices are behind blockers.

In the third example scenario of FIGS. 4 c and 5 c, a communicationsblocker 412 sits in front of computing device 112. It is clear thatbecause a blocker sits in front of each device, neither device may beable to establish direct, peer-to-peer communications, that is, theprocedures of both FIGS. 5 a and 5 b may fail. In this case, the devicessettle for a second best solution. In step 526, presumably afterattempting the procedures of FIGS. 5 a and 5 b, one of the two devices(shown as device 100 but that is not significant) establishescommunications flow 414 with a relay service 416. The relay service isdesigned just for such situations: it accepts communications from eachdevice and passes them on to the other. It is optimized for low delayand high throughput. The relay service sends to device 100 a sessionidentifier. In step 528, device 100 invites, via the rendezvous service400, device 112 to use the relay service to communicate with it. Theinvitation includes the session identifier. Device 112 establishes, instep 532, communications flow 418 with the relay service and gives therelay service the session identifier. With this, the relay service knowsto pass communications between devices 100 and 112. In the parallelsteps 534 and 536, devices 100 and 112 use their communications flows414 and 418, respectively, to the relay service to communicate with oneother. The arrow between these two steps has a dashed outline toindicate that the communications are indirect, being mediated by therelay service.

In sum, by proceeding through the procedures of FIGS. 5 a and 5 b, twocomputing devices can use a rendezvous service to establish direct,peer-to-peer communications even if either one of the two devices sitsbehind a communications blocker. If communications blockers prevent bothdevices from establishing direct communications with the other, then thedevices can use a relay service to communicate indirectly with eachother, providing the illusion of direct communications.

FIG. 6 presents a scenario of communications blocking specific tofirewalls. As discussed with reference to FIG. 2, a firewall may beconfigured to block all communications, based on their addresses andport numbers, that have not been specifically allowed. Computing device112 attempts to establish communications flow 600 through firewall 200to device 100, but the firewall is not configured to accept the portnumber that device 112 is using and so discards the message. FIGS. 7 a,7 b, and 7 c portray a method that device 112 can use to establishcommunications in spite of the blocking firewall. In step 700, device112 attempts to establish communications flow 600 as it normally would,addressing the flow to device 100 and using a port usually open tocommunications. For example, port 80 is often open. If the attemptsucceeds, then devices 100 and 112 can communicate directly with oneanother. Else, device 112 move to step 702 and again attempts toestablish communications flow 600. This time, however, device 112 uses adifferent port number, perhaps one often open on firewalls. Somefirewalls open port 443 for encrypted communications, but will allowanything to pass through. If this attempt succeeds, the procedure iscomplete. Otherwise, device 112 proceeds to step 704 in which itestablishes communications flow 602 with a proxy service 604. The proxymay have privileges beyond those of device 112 and may be able toestablish communications flow 606 with device 100. In so doing, theproxy may use the port originally attempted by device 112 (e.g., port80), may use port 443, or may negotiate with the firewall to use anotherport. This is reflected in steps 706, 708, and 710 of FIG. 7 b. If theproxy succeeds, then as shown in parallel steps 712 and 714, devices 112and 100 can communicate with each other through the proxy. There isnothing special about the order of steps 700, 702, 704, and 708: device112 may attempt these steps in any order. Note that this procedure maybe used whenever device 112 is having difficulty establishing directcommunications with device 100. In particular, it may be useful inconjunction with the procedures of FIGS. 5 a, 5 b, and 5 c.

The methods of FIGS. 5 a, 5 b, 5 c, 7 a, 7 b, and 7 c may be implementedin any number of ways. They may be incorporated into networkcommunications drivers running on the computing devices 100 and 112.That way, the procedures become transparent to users of and applicationsrunning on the devices. In many cases, users and applications need notknow whether they are using direct, peer-to-peer communications or arelay service, the originally chosen port number, another port number,or a proxy service. Of course, this information can be provided to usersand application if desired.

In view of the many possible embodiments to which the principles of thisinvention may be applied, it should be recognized that the embodimentsdescribed herein with respect to the drawing figures are meant to beillustrative only and should not be taken as limiting the scope of theinvention. Therefore, the invention as described herein contemplates allsuch embodiments as may come within the scope of the following claimsand equivalents thereof.

1. A method for a first computing device to establish communicationswith a second computing device, the method comprising: sending a firstinvitation for the second computing device to a rendezvous service;receiving a failure message from the rendezvous service indicating afailed attempt to establish communications by the second computingdevice with the first computing device, the failed attempt responsive tothe first invitation; and sending a second invitation for the secondcomputing device to the second computing device.
 2. The method of claim1 further comprising accepting an attempt to establish communications bythe second computing device.
 3. The method of claim 1 wherein the secondinvitation is sent to the second computing device using an address, theaddress including a port number wherein the port number is 443 or
 80. 4.The method of claim 1 wherein the second computing device is behind acommunications blocker.
 5. The method of claim 1 further comprising:sending a third invitation for the second computing device to arendezvous service, the third invitation specifying a relay service; andaccepting an attempt to establish communications by the second computingdevice via the relay service.
 6. The method of claim 5 wherein the firstcomputing device is behind a communications blocker and the secondcomputing device is behind a communications blocker.
 7. The method ofclaim 5 wherein the communications passes through a port 80 or a port443.
 8. The method of claim 5 wherein the communications passes throughat least a portion of the public Internet.
 9. A computer-readable mediumwhereon is stored computer-executable instructions sufficient to performa method for a first computing device to establish communications with asecond computing device, the method comprising: sending a firstinvitation for the second computing device to a rendezvous service;receiving a failure message from the rendezvous service indicating afailed attempt to establish communications by the second computingdevice with the first computing device, the failed attempt responsive tothe first invitation; and sending a second invitation for the secondcomputing device to the second computing device.
 10. Thecomputer-readable medium of claim 9, the method further comprisingaccepting an attempt to establish communications by the second computingdevice.
 11. The computer-readable medium of claim 9, the method whereinthe second invitation is sent to the second computing device using anaddress, the address including a port number wherein the port number is443 or
 80. 12. The computer-readable medium of claim 9 wherein thesecond computing device is behind a communications blocker.
 13. Thecomputer-readable medium of claim 9, the method further comprising:sending a third invitation for the second computing device to arendezvous service, the third invitation specifying a relay service; andaccepting an attempt to establish communications by the second computingdevice via the relay service.
 14. The computer-readable medium of claim13 wherein the first computing device is behind a communications blockerand the second computing device is behind a communications blocker. 15.The computer-readable medium of claim 13 wherein the communicationspasses through a port 80 or a port
 443. 16. The computer-readable mediumof claim 13 wherein the communications passes through at least a portionof the public Internet.